🗄️ Own WorkflowRun connections and complete schema v1 - #391

Depends on #389.

Stack layer 2 for #365, replacing the authoritative-connection and complete-schema portion of draft #387. This PR does not close #365.

Why

WorkflowRun handles need one provider-owned SQLite/DOFS connection boundary per canonical run path before retained Workspace mutations can be published atomically. The unreleased version-1 database also needs its final complete structure now, without introducing a migration from the unsupported intermediate pre-release shape.

What changes

Before:

Each handle owned a SQLite connection, and schema version 1 contained only workflow metadata and the filtered journal.

After:

Each canonical run path resolves to one provider-owned entry containing the physical SQLite connection, cooperative queue, pinned DOFS wrapper, WorkspaceFilesystem, and synchronous savepoint allocator. Handles are scope-owned leases. Fresh databases atomically receive the complete frozen version-1 schema, canonical content-addressed empty Workspace root, current-root pointer, and journal root association. Existing databases are recognition-only and strict corruption failures remain unchanged on disk.

Foreign-key failures are interpreted as invalid stop reasons only at the two statements that write stop-reason event references. Other Workspace, root, manifest, blob, and journal-root foreign-key failures remain storage failures and roll back their transactions. An XMD-identified database with user_version = 0 is partial initialization and is rejected as corruption without changing the file.

How it works

provider path registry → authoritative connection + cooperative turn → caller-owned transaction → DOFS initialization savepoint → complete v1 schema + canonical empty root

Review guide

Start with: packages/workflow/src/deno/connections.ts

Then review:

1. packages/workflow/src/deno/provider.ts for provider lifetime and atomic initialization
2. packages/workflow/src/deno/schema.ts for the frozen structural manifest and strict recognition
3. packages/workflow/src/deno/workspace/empty.ts for root-format-1 identity and semantic validation
4. packages/workflow/tests/workflow-run-storage.test.ts and workflow-run-journal.test.ts

Look carefully at:

• lease teardown versus provider teardown
• savepoint ownership inside BEGIN IMMEDIATE
• byte-for-byte refusal of intermediate or partial version-1 files
• journal association with the current retained root
• statement-local stop-reason foreign-key classification

What must stay true

• WorkflowRunDatabase.transact() remains the only top-level transaction owner; DOFS initialization nests through uniquely named SQLite savepoints.
• Same-run operations wait cooperatively on one per-entry queue; different run paths remain independent.
• Existing databases are never repaired or migrated; exact structure and empty-frontier semantics are validated before rows are trusted.
• Runtime-specific SQLite, DOFS, SQL, and savepoint types remain inside the Deno adapter.

How to verify it

• deno task setup — passed.
• deno task lint — passed with 0 errors.
• deno task check — passed.
• deno task test — passed: 401 tests, 2,744 steps, 0 failures.
• deno task check:jsr — passed (Success Dry run complete).
• Focused workflow storage and journal suites — passed: 12 suites, 79 steps.
• git diff --check origin/agent/issue-365-1-vendor-dofs...HEAD — passed.
• deno task verify — passed all nine applicable commands under the repository CI Node 22 runtime; the tracked tree remained unchanged.

Scope

Included

• provider-owned authoritative connection registry and scope-owned leases
• cooperative per-run serialization and synchronous savepoint integration
• pinned DOFS initialization on the authoritative connection
• complete frozen WorkflowRun schema version 1
• canonical empty Workspace root, retained reference tables, current-root state, and strict empty-frontier recognition
• minimal journal root association required by the foreign key
• architecture and workflow-storage contracts for this layer

Intentionally unchanged

• no Workspace mutation or durable coordinator API
• no operation-spanning mutation savepoint or guarded journal routing
• no snapshot traversal, restoration, history/fork, public <File>, lifecycle, Worker Shell, Git, FUSE, subprocess, workerd, or garbage collection behavior
• no architecture/specification claims for the later atomic publication layer

New abstractions

• WorkflowRunConnections owns one authoritative adapter entry per canonical run path.
• SavepointManager adapts synchronous DOFS transactions to the caller-owned SQLite transaction.
• Each new abstraction has a concrete provider or transaction consumer.
• No speculative functionality is included.

Risks and limitations

• This layer recognizes only the canonical empty Workspace frontier it creates. General roots and Workspace effect publication remain in later stack layers.
• Unsupported intermediate version-1 databases must be deleted and recreated; they are rejected without mutation.

Scope confirmation

• Every changed file supports the purpose described above.
• Unrelated cleanup and formatting changes are excluded.
• Generated or mechanical changes are clearly identified.
• The description matches the final diff and test results.